The IBM Enterprise Systems Architecture S/390 Principles of Operation (form number SA22-7201-00), and the IBM Enterprise Systems Architecture S/390 Common I/O Device Commands (form number SA22-7204-00) describe the I/O architected structure used in the IBM S/390 systems, such as the IBM S/9000 Central Electronic Complexes (CECs).
The Channel Subsystem Call (CHSC) instruction is an instruction with a single operand which addresses a command request block which contains an operation code field that is capable of containing any of a very large number of operation codes, each of which designates a special command function for the CHSC instruction. These I/O channel subsystem commands perform various types of I/O functions. Some of the prior CHSC instructions operated synchronously. Other prior CHSC instructions operated asynchronously, such as the commands disclosed in application serial No. 07/693,997 (PO9-91-012) previously cited which disclosed and claimed: the "change channel path configuration command", the "change control unit configuration command", and the "change I/O device configuration command". All of these asynchronous CHSC commands have the function of dynamically changing the I/O configuration for a CEC while the CEC is normally operating.
Prior to the invention of the commands disclosed and claimed in application serial No. 07/693,997 (PO9-91-012), a new I/O configuration file was loaded into the CEC's processor controller element, and then the CEC's entire I/O subsystem had to have a power-on reset before it could be made operational with the new configuration.
The invention in application serial No. 07/693,997 (PO9-91-012) disclosed a new way to tailor the I/O subsystem control block structure to represent a particular I/O configuration of channels connectable to CECs, control units connectable to the channels, and I/O devices connectable to the control units. However, that invention did not change the basic control block structure of the I/O subsystem of the CECs. However, the invention in application serial No. 07/898,867 (PO9-92-016) did change the basic control block structure of the I/O subsystem of the CECs by adding the concept of sharing sets of control blocks for each of the I/O resource of channels, control units and devices. The sharing set concept enabled an I/O resource to be shared by a plurality of control programs in a CEC which issued the I/O instructions to the I/O subsystem. These control programs were in different operation systems (OSs) which occupied different logical partitions of the CEC. These partitions are considered logical-resource partitions because they use different parts of the same CEC physical resources, or time share the same resources in the CEC; for example, the main storage is divided by microcode defined boundaries which can easily be changed without changing the physical structure of the main storage.
None of the prior CHSC commands can operate with I/O resources using shared channel paths. The prior CHSC commands can only operate with I/O resources using unshared channel paths. The prior CEC I/O structure required I/O channels that were connected to only a single OS; and the invention in application No. 07/898,867 (PO9-92-016) first enabled a channel to be dynamically switched between the different OSs in a CEC, merely by any OS issuing an instruction requiring the channel--which was then used by the requesting OS if the channel was then available.
Shared I/O resource concept uses the image identifier (IID) invention described and claimed in application serial No. 07/898,867 (PO9-92-016). The IID invention is generally independent of whether or not IIDs, themselves, are hidden from the operating systems (OSs) in the CEC. That application expresses a preference for the IIDs being hidden from the OSs to enable old versions of OSs to operate within a CEC modified with the IID invention to allow shared I/O resources among the OSs. Then, old OS versions may be run in a CEC also running new versions of OSs in its different partitions.
Multiple OSs in a CEC are coordinated by a hypervisor, in which the CPU and storage resources of the CEC are divided among the independently executing OSs. Some hypervisors are structured in internal code (e.g. microcoded hypervisor) and other hypervisors are structured in software (e.g. software hypervisor). A commercial example of a microcoded hypervisor is the IBM S/390 PR/SM (processor resource/system manager), which coordinates resource contentions among independently executing OSs in separate logical resource partitions (LPARs) of a CEC such as the IBM S/9000 model 900. An example of a commercial software hypervisor is the IBM S/370 VM/MPG (virtual machine/multiple preferred guests) system running on an S/370 3090 model J, in which so-called virtual machines (called preferred guests) execute separate OSs in respective logical resource partitions divided by the system software in a software directory.
Prior interpretive execution was obtained in a CEC having multiple independent OSs to increase the CEC's execution efficiency, which is highest when each OS in the CEC is able to have its CPU instructions executed interpretively. Having multiple independent OSs in a CEC requires that the CEC resources be apportioned among the OSs, and that the instructions executed under each OS be restricted to using only the CEC resources assigned to its OS--for example, to execute only within the memory range assigned to the respective OS in the main storage of the CEC.
Configuring a CEC's I/O subsystem involves more than merely considering physically-connected I/O resources, such as a CEC's physical-connected channels, physical-connected control units, and physically-connected devices. Control blocks are provided in the I/O subsystem microcode to electronically control these physical resources. Without these control blocks, the I/O resources alone would be useless to the CEC, because the physical entities alone of these I/O resources cannot be controlled to do work for the CEC.
Accordingly, merely connecting a physical resource to a CEC does not configure that resource into the CEC. This is because the existence of the resource cannot be recognized by the CEC hardware and software until the resource is represented by a control block, which is the entity used by the CEC hardware and software for controlling the physical resource.
In the prior art, a CEC's I/O configuration requires having one control block for each physically-connected I/O resource. The control block contains all of the information needed to control the corresponding I/O physical entity; for example, a busy bit in each control block is provided to indicate whether the physical entity is busy or not, as well as all kinds of other control fields for indicating the current physical characteristics of the entity.
In prior S/370 and S/390 architected computer systems, each channel was configured in the CEC by constructing a single "channel control block" (CHCB) in the CEC's I/O system storage. Each I/O device was configured in the CEC by constructing a single subchannel control block (SCB) in the CEC's I/O subsystem storage. One or more logical control units were configured in the CEC as a shared device cluster by constructing a single logical-control-unit control block (LCUCB). A shared device cluster is defined as a set of one or more logical control units that share devices.
The CHCBs, SCBs and LCUCBs are structured in the I/O subsystem storage, which is not accessible to CEC software, but is accessible to the CEC's hardware and internal code (microcode) to electronically control the corresponding I/O resources physically connected to the CEC.
A control block configured in the system may indicate several states for its physical I/O entity, such as if the entity is usable or not by the CEC's software instructions. For example, the physical resource may be subjected to a "vary off line" command which sets a field in its control block indicating the physical resource is not available for use. Or a "vary on line" command sets the control block field to indicate the physical resource is available for use, although it may be currently busy (indicated by the busy field) and therefore not currently selectable.
Prior art reconfiguration of the CEC's I/O subsystem involves changing these I/O subsystem control blocks. Reconfiguration may add a new control block into the I/O subsystem storage to bring a corresponding I/O resource into the CEC configuration, whether the physical resource was previously-connected or is newly-connected. Or, reconfiguration may delete an existing control block from the I/O subsystem storage to eliminate the corresponding I/O resource from the CEC configuration, even though the resource is still physically connected to the CEC.
In the prior art, the commands to create, modify or delete control blocks in the I/O subsystem are issued by one of the OSs which is executing under the hypervisor's control. Subject to security controls, a properly authorized OS can issue commands that create, modify or delete control blocks which affect resources used by any or all OSs.
Furthermore, two fundamentally different methods are provided in the prior art for obtaining reconfiguration of the CEC's I/O subsystem. They may be generically referred to as static and dynamic reconfiguration methods.